Multi-AZ 対応後の Amazon FSx for Windows File Server を構築してみた
みなさま Xin chao !
以下の弊社ブログでも紹介されている通り、Amazon FSx for Windows File Server (以降 FSx for Windows) のアップデートが大量に発表されました。
今回は、そのアップデートの 1 つである Multi-AZ 環境で、実際に FSx for Windows を構築してみました。
Multi-AZ 構成に関するドキュメント
FSx for Windows の Multi-AZ 構成に関する説明が、以下の公式ドキュメントに記載されています。
内容を抜粋すると、以下の通りです。
- ディスクに記録されるいかなる変更も、別 AZ 内のスタンバイ側に同期的に複製される
- 以下のような事象が発生した際、スタンバイ側に自動的にフェイルオーバーされる
- AZ 機能停止発生時
- アクティブ側サーバーの利用不可時
- アクティブ側サーバーの計画的メンテナンス時
- アクティブ側サーバーの障害検知からスタンバイ側サーバーがアクティブになるまで、通常 30 秒以内にフェイルオーバーは完了する
- フェイルオーバーの前後でファイルサーバーの DNS 名は変わらないため、(DNS 名でアクセスしている限り) Windows クライアントからはフェイルオーバーが透過的に (≒意識せずに) 行われる
- フェイルオーバー後、優先サブネット上の元・アクティブ側サーバーが復旧すると、自動的にフェイルバックされる
- フェイルバックも、30 秒以内に完了する
- フェイルバックは、優先サブネット上の元・アクティブ側サーバーの完全復旧後にのみ行われる
- Linux クライアントは、DNS ベースの自動的なフェイルオーバーをサポートしないため、フェイルオーバー中スタンバイサーバーに自動では接続されない
今回の環境
以下のように、Microsoft AD を使った環境で試してみたいと思います。
VPC や、サブネット関連、および、踏み台 EC2 は構築済みとし、Microsoft AD の作成から始めます。
やってみた
Microsoft AD の作成
まずは、FSx for Windows で使用するディレクトリサービスを準備します。
AWS Managed Microsoft AD (＝Microsoft AD) を選択します。
テスト環境で規模が大きくないため、Standard Edition を選択します。
Microsoft AD の DNS 名, NetBIOS 名, Admin のパスワード を入力していきます。
Microsoft AD のデプロイ先を選択し、ディレクトリを作成します。
Microsoft AD の作成完了まで、しばらく待ちます (今回は 20 分ほどかかりました)。 作成されたら、DNS アドレスを確認します。 踏み台 EC2 を Microsoft AD に参加させる際に必要になります。
FSx for Windows 用 セキュリティグループの作成
FSx for Windows に適用するためのセキュリティグループを作成します。 AWS のドキュメントをもとに、以下のように作成します (今回の VPC CIDR は 10.0.0.0/16 になっています)。
Step 1: Create Your File System - Amazon FSx Windows User Guide
| タイプ | プロトコル | ポート範囲 | ソース |
| SMB | TCP | 445 | 10.0.0.0/16 |
| カスタム UDP ルール | UDP | 445 | 10.0.0.0/16 |
| カスタム TCP ルール | TCP | 135 | 10.0.0.0/16 |
| カスタム TCP ルール | TCP | 1024 - 65535 | 10.0.0.0/16 |
| カスタム UDP ルール | UDP | 1024 - 65535 | 10.0.0.0/16 |
FSx for Windows ファイルシステムの作成
AWS マネジメントコンソールで進めていきます。
Amazon FSx for Windows File Server を選択します。
ファイルシステムの詳細を入力・選択していきます。
ここで注目です。 2019年11月のアップデートにより Deployment type で Multi-AZ が選択できます！
さらに、 Storage capacity で 32 GiB を選択してもエラーになりません！ (今までは 300 GiB が最少でした)
VPC および サブネットは、既に作成済みのものを選択します。 1 つ目のサブネット入力欄が優先サブネット (＝アクティブ側の FSx for Windows が起動する) で、2 つ目の入力欄がスタンバイサブネット (＝スタンバイ側の FSx for Windows が起動する) になります。 セキュリティグループは、先ほど FSx for Windows 用に作成したものを選択します。
ディレクトリについては、先ほど作成した Microsoft AD を選択します。
バックアップウィドウ, メンテナンスウィンドウ を設定します。 これらの設定は、オプション扱いとなっています。
最後に、入力した内容を確認し、[Create file system] をクリックすると、FSx for Windows の作成が開始されるので、完了までしばらく待ちます (今回は 20 分ほどかかりました)。
作成が完了したら、FSx for Windows の DNS 名を確認します。 FSx for Windows 上に作成された共有フォルダにアクセスする際に、この DNS 名をサーバー名として指定します。
踏み台サーバーを Microsoft AD ドメインに参加
FSx for Windows のアクセス元となる踏み台サーバーを、Microsoft AD のドメインに参加させます。 以下の操作は OS 踏み台サーバーの OS 上で行います。
使用する DNS サーバーを Microsoft AD 作成後に確認したものに変更します。
ドメインに参加します。 ドメイン名には、Microsoft AD の DNS 名を指定します。
Microsoft AD の Admin パスワードを入力します。
ドメインに参加できました。 再起動を求められるため、手動で OS の再起動を行います。
踏み台サーバーから FSx for Windows に接続
踏み台用 EC2 に Microsoft AD の Admin ユーザーで、リモートデスクトップ接続します。
Windows エクスプローラーで FSx for Windows の共有フォルダーに接続します。 接続先の指定は、以下のようになります。
\\[FSx for Windows DNS 名]\share
(例) \\amznfsx1234abcd.masawo-ad.test\share
共有フォルダーに接続できました。
共有フォルダーにファイルも保存できました。
最後に、AWS マネジメントコンソールや AWS CLI Command Reference を確認する限りでは、FSx for Windows を手動でフェイルオーバーさせる手段は提供されていない模様です。
fsx - AWS CLI Command Reference
おわりに
特に大量のファイルを保存している Windows ファイルサーバーの運用は、確実なバックアップや、可用性の担保など、地味に辛いものがあります。
その Windows ファイルサーバーの機能をマネージドサービスとして提供する FSx for Windows はこれまでも利用可能でしたが、標準機能では Single-AZ 構成でしか構築できず、高可用性が求められる環境では、別途 DFS を使用する必要がありました。
今回の Multi-AZ 対応により、高可用性が求められる環境でも、より一層 FSx for Windows を使いやすくなったのではないかと思います。
